The Fulmine DemoApp Tutorial

The Fulmine distribution includes a simple GUI application that can be used to demonstrate the core abilities of Fulmine. This tutorial will start two Fulmine contexts exposed using the DemoApp GUI. Records will be created and subscribed for between the contexts. The records will be represented in a JTable within the GUI.

Run the fulmine.demo.DemoApp class. The following window appears. Type the values as shown below.

Click OK…

A window appears as below. This is the Fulmine context “app1”.

Before creating app2, we will subscribe for records from app2. This will demonstrate the ability for a context to subscribe pre-emptively for records.

Click the menu item Actions->Subscribe Record…

Enter details as below.

Click the OK button...

This subscribes for records with identities of “rec.*” from a context called “app2”. The type and domain values are -2, this is the wildcard match for the type and domain and will match any value.

At this point, nothing will actually show in the main window for app1. This is because app2 does not exist yet and there are no records.

Run a second instance of the DemoApp class. Enter values as below.

Click OK…

The app2 context is now created.

In App2, select Actions->Add Record and enter values as shown below

Click OK…

This will create a local record using these details. App2 will show the record as in the screenshot below.

App1 also shows this record as the subscription that was issued matches the newly created record. The domain is “null” because it is a user defined value (1) and this has no human-readable value lookup in app1. The context field of the record shows the ‘native context’ for the record. In this case, the record was created by app2 so its native context is app2.

Now we will add a field to the record. In App2, click on the row, and select Actions->Add Field…

Enter details as shown below.

Click OK…

The field appears in app2 and app1

In app1, edit the value of field1 to “hello” and press return. The field value changes in app 2 and app1. This shows how a remote context has changed the value of a remote container’s field. What happens is app1 sends an RPC to app2 to update the field. App2 updates the field and distributes the change to app1.

In app2 add a second field as below…

A new field, “field2” will exist in both apps now.

Now, in app1, try to change the value. This will not work. This is because the field permissions are not compatible with the context’s permissions; the field was created with permission code=2, application code=2 but app1 has application code=1 and permission code=1. Something to be aware of; the permission model for the DemoApp is simple and performs exact matches of the application code and permission codes.

In app2, change the value of field2 to “world”. Only app2 shows the change, this is because the field is in a local container; permissions don’t apply for locally created container fields.

In app2, add another record as follows:

Click OK…

Only app2 will show the record

This is because the subscription issued by app1 was for “rec.*” and this regular expression does not match “another record” so the newly created record is not subscribed for.

That’s it as far as a walk-through goes for the DemoApp. This has shown most of the key features of Fulmine. Feel free to experiment with the app. A few suggestions:

1) Kill and restart app2, recreate the record “rec1”, see how app1 behaves.

2) Subscribe for every record in a context to see what is going on (use .*, -2, -2)

3) Subscribe for a record from app1 (this will demonstrate bi-directional subscriptions)

4) Start a 3^rd context.

One thing to note: the framework domain is 0; these types of records cannot be updated remotely.